Computers have evolved from the traditional stand-alone type of computer to computer systems utilizing computers distributed through a network. Some of these distributed computers remain traditional computer systems, while another type of computer has evolved, called an “embedded” computer. The distributed computers communicate with one another by utilizing defined transport protocols. For any two computers in a distributed system to communicate directly, they must both have installed and utilize the same transport protocol, and be capable of using that protocol on the type of network that connects them.
The network and the computers connected to it can be utilized to create distributed applications, which run simultaneously on more than one computer in the system. Many such distributed applications utilize object-oriented programming, wherein the programmers define not only the data type of a data structure, but also the types of operations that can be applied to that data structure. In this manner, the data structure becomes an object that includes both data and functions. A principal advantage of object-oriented programming techniques is that they enable programmers to create modules that do not need to be changed when a new type of object is added to the software. The programmer can simply create a new object that inherits many of the features from the objects already existing in the system. This facilitates the modification of object-oriented programs since the underlying objects do not need to be changed. Object orientation suits distributed programming well, as modularizing the application in terms of objects makes it easier to reason about the different parts of the application, that are running on different computers in the network. In an object-oriented distributed system, one or more objects that constitute part of the distributed application will be located on each of the computers that the application is running on. The foregoing notwithstanding, distributed applications still can be and sometimes are built using non object-oriented methods.
Distributed systems are very often implemented with the help of a supporting sub-system called “middleware.” Middleware is commonly utilized to hide the operating system (O/S) calls and the network transport protocol programming required to build the distributed computer system. Non-object oriented middleware systems such as Message Oriented Middleware (MOM), or queue based middleware fulfill this task of isolating the application from the O/S and the transport particulars without necessarily imposing an object orientation upon the application builder. One example of object oriented middleware is the Common Object Request Broker Architecture (CORBA), which is an architecture that enables the pieces of distributed programs in the forms of objects to communicate with one another regardless of what programming language they are written in or what operating system they are running on. There are a number of implementations of CORBA and several competing architecture models, such as Microsoft's Distributed Component Object Model (DCOM).
When using middleware, such as CORBA, the transport protocols that are used are by default fixed to one or more of the most common transport protocols, such as Transmission Control Protocol (TCP), which is one of the main protocols in the familiar TCP/IP protocol suite (the Internet protocol (IP) deals only with packets, whereas TCP enables two hosts to establish a connection and exchange streams of data). In the simplest implementation of middleware, the support for the selected protocol or protocols is written as part of the implementation of the middleware package. If the middleware package supports multiple protocols, the distributed applications developed using the middleware may or may not be offered a way to select which of the protocols is used. The choice of protocol will be something that can be specified via a call in the middleware's Application Program Interface (API), which is the set of functions or method calls that is used to build the distributed software application. However in this simplest implementation, the middleware package is fixed with respect to the communication protocols that it will accept, and the applications can only choose from those protocols that the middleware was made aware of when it was implemented.
Support can be added for another desired protocol, but it requires adding code to the source code for the middleware package. The source code for the middleware package then must be recompiled, which results in a new version of the middleware package. This recoding and recompiling process typically is performed by a middleware vendor or by a very experienced customer who must have access to the source code for the middleware package and is prepared to accept the version that they recompile is now different than the standard middleware package.
The risk is that the customer modifications to the package or the process of recompiling the code on the user's machine may produce unexpected changes in the middleware package's behavior. The middleware vendor typically will limit the liability that they will accept for programs modified by the customer, especially if the source code also has been modified. The code to support the new protocol must be integrated fully into the existing source code of the middleware package, and may require modifications to the software architecture of the middleware package. Accomplishing this requires highly specialized knowledge of the implementation of the middleware package, which is usually highly complex and may be large in number of lines of code. It requires highly skilled programmers and a large amount of programming time. Along with the risk previously discussed, there is the additional high cost of obtaining a source code license. Most middleware package licenses are expensive because of the investment in the complex middleware package code that the vendors wish to protect. Therefore, undertaking the additional support for new protocols is not a viable option for most users of middleware software.
Thus there is a need for the capability of adding different transport protocols to a middleware based application, which can be added by the application programmer without rewriting the middleware program itself. The mechanism by which this can be accomplished is a new API, known as a Pluggable Protocol Interface. This API specifies a set of functions to be implemented by a plugged in protocol provider allowing the middleware to use a common set of protocol functions (e.g. establish a connection, send data, receive data . . . ). Additionally this API specifies a set of functions which will allow the protocol provider to announce protocol events to the middleware (e.g. signal_data_available, new_connection, . . . ).
A significant problem arises when the middleware, via the pluggable protocol interface, must support an arbitrary protocol. In particular, the problem of how signaling takes place between the arbitrary protocol and the middleware package. The protocol may not use endpoint identifiers that the middleware can use directly to block or wait upon for data or events. For example, for the internally supported common protocols (e.g. TCP/IP), the middleware can directly utilize the underlying O/S mechanisms (file descriptors, select, read and write).